-
Notifications
You must be signed in to change notification settings - Fork 62
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Merge physical plan evaluator and basic planner to main
#612
Conversation
* Additional pipeline abstractions to share more code when testing the CompilerPipeline and future PlannerPipeline
* Add 3 query planner passes. - AST->logical - logical->resolved - lesolved->physical. Not yet integrated with anything--that will come in a future commit.
* Add 3 query planner passes. - AST->logical - logical->resolved -resolved->physical. Not yet integrated with anything--that will come in a future commit.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, all the incorporating PRs have already been reviewed by maintainers.
Please wait for the second reviewer approval before merge. We want to have the 2-person verification for this merge.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I gave a cursory look at all the changes. The logic based on the documentation and prior discussions looks reasonable to me, and I think it can be merged to main
. The comments I left were all minor and mostly dealt with documentation.
*/ | ||
open class SqlException( | ||
override var message: String, | ||
val errorCode: ErrorCode, | ||
val errorContext: PropertyValueMap? = null, | ||
errorContextArg: PropertyValueMap? = null, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does this need to be nullable (i.e. what does a nullable errorContextArg define)? The errorContext
definition on L49 could be redundant since a null errorContextArg
will default to an empty property value map.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's nullable because it always has been nullable. Changing this to an argument and defaulting the errorContext
property to an empty map if errorContextArg
is null was a way of simplifying error handling code that reads context properties without changing all of the call sites of this constructor (a few direct, but many indirect) to conform its new signature, which would have resulted in many more noisy diffs in this series of PRs. If you want, I can undo this change in another commit against this PR, but I would consider making this argument non-nullable to be out of scope of this work.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok got it. I don't think it needs to be addressed in this PR. Could you make an issue and link here regarding making errorContextArg
non-nullable?
lang/src/org/partiql/lang/eval/builtins/DynamicLookupExprFunction.kt
Outdated
Show resolved
Hide resolved
lang/src/org/partiql/lang/planner/transforms/VariableIdAllocator.kt
Outdated
Show resolved
Hide resolved
lang/test/org/partiql/lang/eval/EvaluatingCompilerOffsetTests.kt
Outdated
Show resolved
Hide resolved
lang/test/org/partiql/lang/planner/transforms/AstToLogicalVisitorTransformTests.kt
Outdated
Show resolved
Hide resolved
Co-authored-by: Alan Cai <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for addressing the feedback. Given @am357's previous approval and the fact that my feedback was minor (mostly related to documentation), I think we can merge this feature branch into main
.
Merges the following PRs to `main`: - #583 - #584 - #587 - #588 - #589 - #609 - #590 - #592 Also, this adds a TODO comment (ea40e4a, requested by @am357 in offline chat) and excludes `PlannerPipeline` from the new aggregate tests which were pulled in when merging from `main` and were not part of the other PRs (34025b3). By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
Merges the following PRs to `main`: - #583 - #584 - #587 - #588 - #589 - #609 - #590 - #592 Also, this adds a TODO comment (ea40e4a, requested by @am357 in offline chat) and excludes `PlannerPipeline` from the new aggregate tests which were pulled in when merging from `main` and were not part of the other PRs (34025b3). By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
Merges the following PRs to `main`: - #583 - #584 - #587 - #588 - #589 - #609 - #590 - #592 Also, this adds a TODO comment (ea40e4a, requested by @am357 in offline chat) and excludes `PlannerPipeline` from the new aggregate tests which were pulled in when merging from `main` and were not part of the other PRs (34025b3). By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
This will merge the following PRs to
main
:UniqueIdResolver
toMetadataResolver
#609Also, this adds a TODO comment (ea40e4a, requested by @am357 in offline chat) and excludes
PlannerPipeline
from the new aggregate tests which were pulled in when merging frommain
and were not part of the other PRs (34025b3).By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.